This question and answer file contains APPN-related questions from APPN vendors and customers, and the answers provided by APPN architects and product designers, where appropriate. These Q&As deal with the following subjects, in that order, over the period Sept. '94 - Mar. '95. Subject: SNA, APPN, and ATM Subject: VTAM Estimating Storage Diskette Subject: ADSM connectivity Subject: APPN using /36 Subject: Class of Service Subject: Dependent LU Subject: XID rules Subject: Numerous Base & Options Questions Subject: COS Support in End Nodes Subject: Errors Detected in XID Processing Subject: Sense data for inconsistent netid.cpname on activation XID3 Subject: Sense data for inconsistent netid.cpname on activation XID3 Subject: AFTP to FTP by Anynet Subject: APPN Design Using a Connection Network Subject: APPN and SNI =============================================================================== SUBJECT: SNA, APPN, and ATM DATE: 9/22/94 OWNER: Anthony Johnston QUESTION: This section of the forum has been far too quiet of late so to 'provoke' some discussion:- " 1) Subarea SNA is not a 'clasically' routable protocol, however APPN does have such capabilities. 2) ATM will make redundant the requirement for access protocols like SNA/APPN to need to be routed. 3) Given the big push IBM is giving to ATM why are IBM bothering with introducing a (newish) routable protocol, and will it be worth the pain for 3270 customers to implement APPN" I'm not convined of some of those statements but as my English teacher used to say... please discuss... RESPONSE1: For what it's worth ..... > " 1) Subarea SNA is not a 'clasically' routable protocol, however > APPN does have such capabilities. I disagree with this statement. I've had no problem in my career routing SNA. I _did_ have to implement a subarea node to do it, but it could be done. IBM published everything I needed in its (only at the time) FAPL, SC30-3112-2. > 2) ATM will make redundant the requirement for access protocols > like SNA/APPN to need to be routed. I am not well versed in ATM, so I'll make my point have nothing to do with ATM. I remember being told Bisync would be going away once SNA (ie. VTAM) shipped en mass. Things will not change overnight. The data lives on IBM gear. (I'll even argue IBM Mainframes, and will not move anytime soon, but that can be saved for a different forum and/or thread.) The appls which access the data use SNA and SNA is an intergal part of accessing the data. If it was easy to change from say, 3270 access to APPC, it would be done already. Instead, APPN (which worked fine day one for APPC) is being changed to deal with 3270/LU2 properly. So, the SNA (ie. RH and SNF&EFI of TH) will have to be in the ATM from an "appl" to "appl/device" point of view. SNA is still there as a resule (I conceed that the "routing isn't.) As ATM is installed, there will still be older gear which will route (via SNA IMHO) from the ATM "stage" to the say, LAN stage. > 3) Given the big push IBM is giving to ATM why are IBM bothering > with introducing a (newish) routable protocol, and will it be > worth the pain for 3270 customers to implement APPN" The addition of HPR to APPN will fit with ATM nicely. If I remember Marcia Peters pitch at Share last August, (APPN Architect), HPR is being designed with ATM in mind. My 3270 users are using APPN and they don't even know it. VTAM now supports APPN (and continues to support subarea.) They have no clue (nor do they care) that the routing is FID2 in lieu of FID4. RESPONDENT: Michael Cambria RESPONSE2: >IBM published everything I needed in its (only at the time) FAPL, SC30-3112-2. Very true... but as you said... > I _did_ have to implement a subarea node to do it, but it could be done. You try telling say a DEC shop who needs to integrate their (existing) network with SNA that all they have to do it implelent a subarea node - how many router vendors actually route SNA? >The data lives on IBM gear. (I'll even argue IBM Mainframes, and will not move anytime >soon, but that can be saved for a different forum and/or thread.) The appls which access the >data use SNA and SNA is an intergal part of accessing the data. I couldn't agree more. SNA/APPN as an access protocol will (IMHO) be around for some time, my point was that as a routing protocol perhaps APPN is 5 years too late? >The addition of HPR to APPN will fit with ATM nicely. If I remember Marcia Peters pitch at >Share last August, (APPN Architect), HPR is being designed with ATM in mind. I didn't mean to imply that it wouln't, I was trying to indentify the (potential) areas of overlap between the two technologies. As the company SNA (and APPN) bigot It was my intention to provoke comments. RESPONDENT: Anthony Johnston RESPONSE3: Hi Anthony, I'll bite. >1) Subarea SNA is not a 'clasically' routable protocol, however APPN does > have such capabilities. Depending of how you grew up in this industry you will have a different perception of what the phrase "classically routable" means - so let me make it quite clear that I grew up with IBM mainframes and SNA/SDLC and SNA/X.25 networks. I have since had exposure to LAN protocols, TCP/IP, Frame Relay and ATM. It would perhaps be helpful if you state your background so we can understand the context of your terminology - but please understand, I welcome your questions and am enthusiastic about discussing them with you. Now on to the substance. The SNA subarea protocol *IS* eminently routable. It is hamstrung by arduous manual path update procedures, but none the less, any SNA Subarea Node can route to any other SNA subarea node within the parameters of addressing limitations etc. The problems is that most SNA nodes are NOT subarea nodes, they are bastardized adjuncts to the powerful subarea network. This was done for the sake of simplifying implementation and reducing cost - but the end result of course is that most SNA nodes do NOT have a routing capability. Protocols like TCP/IP differ in that all nodes have similar routing capabilities with the diffirentiation between a host and an IP router (gateway - whatever) is slight and is the difference between running a few daemons or not, or being multihoned etc. There are very few non-IBM implementations of SNA subarea nodes. People like Cisco thought about it for a while and then abandoned that idea realizing that it is no trivial task. On the other hand, there are very many non-IBM implementations of non-subarea SNA nodes, even on DEC machines which you alluded to being a problem area. Perhaps if IBM had given away free, the source code for subarea nodes, as was the case with IP routing nodes, there would be more SNA subarea nodes. Having said that though, the SNA subarea model is not scalable in a practical sense to hundreds of thousands of nodes so APPN is a much better route. >2) ATM will make redundant the requirement for access protocols like SNA/APPN to need to be routed. Hopefully one day ATM will make redundant the need for TCP/IP, APPN etc. But until all platforms have access to native ATM APIs and services, applications will still have to be written to existing communications APIs such as sockets, SNA APIs etc. The industry is a long way of having any ATM API on all platforms, let alone the preferred path of a standardized API. Hopefully this will devleop quickly as it would have a truly important impact on networking. Additionally, if ATM adaptation layers don't evolve to provide all the services that existing transport layer, session layer and presentation layer protocols do, then some protocol layer between the application and the network may be desirable for certain transacations (especially client/server database update transactions). >3) Given the big push IBM is giving to ATM why are IBM bothering with introducing a (newish) routable protocol, and will it be worth the pain for 3270 customers to implement APPN" There are two important areas of networking protocols - those used as an internetworking infrastructure (as TCP/IP is today) and those used as end to end protocols (as TCP/IP, SNA etc are today). ATM will have an important role in the intermediate future of phasing out TCP/IP as the preferred internetworking infrastructure protocol. But during this time, the use of TCP/IP and SNA/APPN will continue to grow as end to end (i.e. applicationm to application) protocols untill everybody switches over to native ATM APIs - if this ever happens of course. Is it worth the pain to switch over to APPN? To some extent IBM's committment to its installed base is a paralysing force on its strategic direction. On the other hand, there committment to there installed base often ensures that very slow migration to new technologies is not nearly as painful as you might imagine. Additionally, please remember that APPN is much more than just a transport layer as is TCP. APPN has directory services (DNS like), session services (application to application services) just to name a few features. And while IBM's BBN has many such services included for its own purposes (which I hope IBM will extend outwards to reduce the duplication in APPN networks), many ATM switch implementations will not have such added value. Thanks for posting the questions, RESPONDENT: Mark Seery RESPONSE4: Hi Mark, My backround is 15 years experience of SNA (mainly subarea) - as VTAM systems programmer through to Communications Manager of a large multi-protocol network, and laterly as an internal consultant on a large comms project. I am a grate fan of SNA - and I would like to see APPN really take off, but I have grave doubts over APPN as a routing protocol, despite (IMHO) its obvious technical superiority to TCP/IP/DECnet etc. >perception of what the phrase "classically routable" means I know what you mean!!! I deliberatly put that phrase in quotes. >The SNA subarea protocol *IS* eminently routable. It is hamstrung >by arduous manual path update procedures >....but the end result of course is that most SNA nodes do NOT have a routing >capability. Playing devils advocate, it ocurrs to me that a FID2 address on its own isn't a particularly usefull thing - without that is a subarea node to perform boundary processing. It is this behaviour that leads me to my assertion that it is not a routable protocol. >very many non-IBM implementations of non-subarea SNA nodes, even on DEC machines. Granted (and my company uses many non IBM PU2.0 impementations). My original point was that if (as we are at the moment) you are attempting to create a non-protocol specific network, its easier to to do it for non SNA envrionments. SNA (for some very good reasons) must always be treated seperatly in some way - ie Data Link Switching, Clear channels etc. >Hopefully one day ATM will make redundant the need for TCP/IP, APPN etc. But >until all platforms have access to native ATM APIs and services. I'm not convinced that native ATM API's are a necessity. I still thinks that various *access* protocols (and I include APPN in this) will be required for a very long time, only they won't be used for routing. > On the other hand, there committment to there installed > base often ensures that very slow migration to new technologies is not nearly > as painful as you might imagine. Well a 3270 dumb device shop (sorry 'fixed function terminal shop') might well argue that the cost of uprgading VTAM/NCP and 3174 contollers to support DLS/R might not be entirely pain free. But I do take your point. Finally. I really would like to see APPN *really* take off, its technically superior to other equivalent protocols, but I have this horrible feeling that, due maily to internal politics within IBM, that its already too late for APPN to be as sucessfull a technology as it deserves to be. I'd love to be proved wrong on this one but... Anyway thanks for the discussion. RESPONDENT: Anthony Johnston RESPONSE5: Your point about FID2s is well taken, its just ever since my early days with SNA I had this realization that the boundary network was really quite a different beast from the subarea network - and in many ways was not really, IMHO, consistent with the goals and spirit of SNA, but a business decision based on economics. What I mean by that is simple. it is fairly well known that a decision was made to put the intelligence of the network in the subarea FEPs and Hosts rather than the peripheral network because there were fewer FEPs and hosts than cluster controllers and terminals and therefore the network would be cheaper for the customer. In my opinion this decision compromised the architecture and led to an implementation which IBM and its customers have been struggling with for a long time. Having said that, IBM should have been much more aggressive about roling out APPN, and leaving till 1991 to fully embrace it was rediculously late in the game. It's seed has been around since the early 1980's and it has officially been around since about 1986. I worked for a company that was screeming for APPN type functionality in 1984 - but like other companies, was let down by IBM's attempts to deal with that customer need - 3745 LU6.2 routing is just not the same as full blown APPN. Is it too late for APPN? Well of course the market has run away now in a different direction and of course TCP/IP is offered as a standard feature on many platforms - Unix, NT, Chicago, LAN Server etc. How many platforms is APPN a standard offering on? Of course you only get what you pay for, but then its harder to get budgetary permission to pay for things these days, so people will tend to use what is free, where possible. Are there many loyal SNA/IBM customers out there? Sure there are and many will migrate to APPN so it will certainly be used. The most hopeful aspect for APPN in this regard would be when broadband technology takes off. I don't believe the TCP/IP community is being aggressive as it should be at addressing high-speed networking. Some TCP/IP problems that are a minor annoyance and today's speeds will be a real PITA at high speeds, and of course the TCP/IP community is consumed with issues such as addressing and security etc. If IBM can get HPR established then things will certainly be intersting, but just the same, the industry has been driven in the last ten years from the bottom up - and if people choose to use there "free" TCP/IP stacks, then network managers will have to respect that. RESPONDENT: Mark Seery RESPONSE6: > You try telling say a DEC shop who needs to integrate their > (existing) network with SNA that all they have to do it implelent > a subarea node They should buy it from me 8-) Actually, I consult to DEC for their PU5. So Digital could sell it to any of their customers. > how many router vendors actually route SNA? None. The first that does wins BIG time IMHO. I'm waiting for my phone to ring 8-) > I couldn't agree more. SNA/APPN as an access protocol will (IMHO) > be around for some time, my point was that as a routing protocol > perhaps APPN is 5 years too late? The more and more I loot at what APPN is evolving to, it looks more and more like subarea protocols! HPR is very very similar to VR/ER. It solves the same problem. It is dynamic in its definition of routes, which is new. When was the last time you looked at GDS variables on the CP-CP session? Look familiar? > I didn't mean to imply that it wouln't, I was trying to indentify > the (potential) areas of overlap between the two technologies. If I were remotely qualified to comment on ATM, I'd say more on HPR/ATM. Sorry, your out of luck. Perhaps someone from IBM (or others) will jump in? RESPONDENT: Michael Cambria RESPONSE7: I'd like to add my 2 cents concerning APPN: Keep in mind these two points: 1. APPN is growing in both interest and in use among IBM's customers. Sure, it has been slow coming out in our products, and because of this APPN's growth factor has been, and still is, fairly slow. But it is growing among our customers. 2. Several major enhancements are just now starting to be introduced in APPN products. These are: a) DLUR, which allows dependent LU traffic to be routed much more efficiently and can be used to offload DLU routing from 3745s, and b) HPR, which dramatically improves both session reliability and performance in APPN networks. Many customers consider at least one of these (probably both) functions absolutely critical for their environments, and have been patiently waiting for IBM to deliver products that implement them. Well, they are starting to arrive. HPR is still just around the corner, but is getting much closer.....IMHO the true test of both the acceptance and reliability of APPN will not take place until customers get a taste of what DLUR and HPR offer to their networks. RESPONDENT: Tim Hefel RESPONSE8: Thanks for the comments. >APPN is growing in both interest and in use among IBM's customers Sure but how many of those customers are implementing APPN rather than TCP/IP in a multiprotocol network? >Several major enhancements are just now starting to be introduced in APPN products Whilst I can understand what you are saying - be patient - the real world is not waiting for these facilities, as one vulture once said:- "patience my a** lets kill something!" IBM must sell APPN hard - not just on a technical level - but to senior customer management, and not just to existing IBM customers. >IMHO the true test of both the acceptance and reliability of APPN will not take place until >customers get a taste of what DLUR and HPR offer to their networks. Lets hope (for all of our careers) that you're right! RESPONDENT: Anthony Johnston RESPONSE9: > IMHO the true test of both the acceptance and reliability of APPN > will not take place until customers get a taste of what DLUR and > HPR offer to their networks. I belive that now that VTAM supports APPN "seamlessly", APPN is starting to have a chance. After all, when push comes to shove, the data lives in some VTAM appl. As these systems use APPN without the need to port their applications (appls are the reason for the network after all), they will see its benefits. As for DLUR, I think it is another way of doing the same thing that already exists. Our staff now has to troubleshoot 2 ways of initiating a session (3 if you count the way we know and love in the all dependent lu days.) I'll use an example to describe what I mean. Our VTAM NN has some local LUs (appls or PU2.0 3270s). When they logon (simlogon, logon applid etc.) we see GDS locates and all the APPN that you'd expect (but not documented) to see. Since the VTAM is NN only and no longer a subarea node, this is all it can do for ILU=SLU (Initiating LU, not Independent LU). Perfect, an all APPN solution. My CM/2 system on the outskirts of the APPN network could EASILY do the same thing (at least architecturally), but instead, they decided to implement DLUR instead. Our staff now has to deal with dependent LU flows in an APPC pipe. There is additional overhead as there is with any "Tunneling". At least in this case the tunneling is only for ACTPU/ACTLU type flows. But still, if a backup host (DLU/S) in a CMC type config was to takeover, time is important. First you must have the DLU/S find the backup DLU/S (or vice versa) via APPN. Since this is a backup, chances are that the new DLU will not be a cached. We then must If the dependent LUs were made Independent LUs (just as a VTAM SLU doing an SIMLOGON _is_ today when VTAM is an APPN node only), we would eliminate the ACTPU/ACTLU etc. all together. No dependent LU gen required at the "host", no "recovery" needed if the owning SSCP failed. All the things APPN has as strong points. This brings me to my biggest concern re APPN. I feel that DLUR, whether intentional or not, is encouraging people to continue to build DEPENDENT LU products and not independent. Case in point, CM/2, one of IBMs own products. If APPN already exists (as is the case in CM/2), it is much easier to have an independent LU initiate as SLU that to build DLU/R. The next 3174 (which also is already an NN) could do likewise. All those display stations could become independent LUs with the next rev of microcode. The "logon applid(tso)" a user enters need not go any father than the CP in the 3174. RESPONDENT: Michael Cambria RESPONSE10: "how many sites do you know that are still using RIP? Plenty!" I agree. But standard RIP does not address the slow convergence problem and also has some serious security concerns. Thoses organizations that rely on RIP do so at their own risk. Also, as a RIP-based network grows so does the amount of overhead (broadcasts). Standard RIP also has problems when trying to select optimal routes, load level, class of service, etc. Sooner or later organizations have to move to something else. Sadly, from what I have heard, OSPF has perfromance problems wrt the amount of time it takes to select optimal routes. So using the "standard" versions of RIP and OSPF both have problems right now. Which means we are back to vendor specific solutions. RESPONDENT: Jerry Golick RESPONSE11: Tim: Thanks for the post. Yes I agree. Both HPR and DLUR will be important. Also, IBM customers will be interested. They need it if they want to enjoy the promise of CPI-C/APPC/LU6.2 functionality. My points is how much has IBM done to promote APPN outside of the "old" SNA community? I have read Marcia Peters papers on the subject (which IMO were excellent), and I know that people like Kevin Tolly have written positive reviews, but where is the marketing? RESPONDENT: Jerry Golick RESPONSE12: > I'll use an example to describe what I mean. Our VTAM NN has some local LUs > (appls or PU2.0 3270s). When they logon (simlogon, logon applid etc.) we see > GDS locates and all the APPN that you'd expect (but not documented) to see. > Since the VTAM is NN only and no longer a subarea node, this is all it can do > for ILU=SLU (Initiating LU, not Independent LU). Perfect, an all APPN > solution. > > My CM/2 system on the outskirts of the APPN network could EASILY do the same > thing (at least architecturally), but instead, they decided to implement DLUR > instead. Our staff now has to deal with dependent LU flows in an APPC pipe. > There is additional overhead as there is with any "Tunneling". At least in > this case the tunneling is only for ACTPU/ACTLU type flows. Easily is a matter of perspective. The processing which each DLUR node would need to implement isn't just the APPN flows (Locates, etc.) which are sent, but also the internal SSCP processing currently provided by VTAM. This support has been evolving for 20 years now and has become rather complex. Granted, each DLUR product could implement this logic in addition to the APPN flow support, but it would require lots of code and would be quite error prone. > But still, if a backup host (DLU/S) in a CMC type config was to takeover, time > is important. First you must have the DLU/S find the backup DLU/S (or vice > versa) via APPN. Since this is a backup, chances are that the new DLU will > not be a cached. We then must This should be similar to what you see today for SSCP takeover. The DLUR will notify the DLUS about any active LU-LU sessions during ACTLU processing. These flows are the same as the ACTLU flows between NCP and VTAM. Once nice thing about DLUR/S, though, is the DLUR node can activate the SSCP-PU sessions to the backup DLUS node once it looses connectivity to the primary DLUS node. > If the dependent LUs were made Independent LUs (just as a VTAM SLU doing an > SIMLOGON _is_ today when VTAM is an APPN node only), we would eliminate the > ACTPU/ACTLU etc. all together. No dependent LU gen required at the "host", no > "recovery" needed if the owning SSCP failed. All the things APPN has as > strong points. This brings me to my biggest concern re APPN. Actually, the VTAM SLU *is* a dependent LU, not an independent LU. VTAM simply implements native APPN support for dependent LUs. It is this support on which DLUR/S builds. The VTAM DLUS performs all the necessary APPN logic (Locate-Cdinit, session queueing, etc.) on behalf of the dependent LU as though it were actually local. > I feel that DLUR, whether intentional or not, is encouraging people to > continue to build DEPENDENT LU products and not independent. Case in point, > CM/2, one of IBMs own products. If APPN already exists (as is the case in > CM/2), it is much easier to have an independent LU initiate as SLU that to > build DLU/R. Actually, DLUR is an order of magnitude simpler to implement than providing full support for dependent devices. And you get to keep using existing network management tools, such as NetView, to manage the dependent devices. RESPONDENT: Roy Brabson RESPONSE13: > Actually, the VTAM SLU *is* a dependent LU, not an independent LU. > VTAM simply implements native APPN support for dependent LUs. It > is this support on which DLUR/S builds. The VTAM DLUS performs > all the necessary APPN logic (Locate-Cdinit, session queueing, > etc.) on behalf of the dependent LU as though it were actually > local. This is why I specifically used SIMLOGON in my example. Yes today, for migration etc. I suppose, the opening of an ACB still uses ACTLU/rsp(ACTLU). However, I could write from scratch something that bypasses all this stuff and the 20 years of evolution you mention. The VTAM appl implementation is a dependent LU, but architecturally, it did not have to be. The SIMLOGON "Init-Other" RU could have been an APPN Init-Self message for example. There is no need for ACTPU/ACTLU. Now I have _NO_ problem with VTAM implementing things this way. I would have too, especially if I still had to deal with a) an existing base and b) subarea network. My point was simply that the architecture and ANY NEW PRODUCTS alla CM/2 didn't have to keep the dependent LU SNA going. I've printed you message and will digest it fully. I wanted to make this quick point now. Time permitting, I'll have more for you latter. RESPONDENT: Michael Cambria - TeamOS/2 Boston RESPONSE14: > This is why I specifically used SIMLOGON in my example. Yes today, for > migration etc. I suppose, the opening of an ACB still uses > ACTLU/rsp(ACTLU). However, I could write from scratch something that > bypasses all this stuff and the 20 years of evolution you mention. The VTAM > appl implementation is a dependent LU, but architecturally, it did not have > to be. The SIMLOGON "Init-Other" RU could have been an APPN Init-Self > message for example. There is no need for ACTPU/ACTLU. Sorry, I missed the part about SIMLOGON intermixed with the stuff about dependent SLUs. SIMLOGON is a function of the PLU application, not the dependent SLU. When the appl invokes SIMLOGON, it doesn't know (nor does it need to at that point) whether the SLU is independent or dependent. DLUR/S provides support for dependent SLUs, not VTAM appls. As such, SIMLOGON really doesn't apply to DLUR/S. RESPONDENT: Roy Brabson RESPONSE15: > Sorry, I missed the part about SIMLOGON intermixed with the stuff > about dependent SLUs. SIMLOGON is a function of the PLU > application, not the dependent SLU. When the appl invokes > SIMLOGON, it doesn't know (nor does it need to at that point) > whether the SLU is independent or dependent. DLUR/S provides > support for dependent SLUs, not VTAM appls. As such, SIMLOGON > really doesn't apply to DLUR/S. Your still missing my point and/or I am not making it clearly. I am trying to point out that since an LU can hook into APPN and drive a locate (via actpu/actlu etc. as in a LOCAL SNA device to VTAM), I can easily cut out all that dependent stuff, turning what was a dependent LU into an independent LU. That is why I used SIMLOGON (Initiating LU = OLU = SLU) in my example. This VTAM Macro could be changed to impement the APPN INIT_HS(?) message to its local CP in lieu of keeping the current INIT-Other logic (and the dependent LU actlu etc.) which it also requires (and keeps the LU "dependent"). I tried to use a "change" in implementation of the current product to illustrate my point. I don't care how bad the VTAM code (or CM/2 or ..) is implemented, which may keep this from being done. I also understand that if it works, don't fix it, so even if the code could "easily" be changed, there is no reason/market to do so. I understand all that. That is not my point. I tried to make my point by describing changes to existing products. In architectural terms only, there should be NO reason why non APPC LU types (which in years gone by were dependent) can't become independent. A brand new, from scratch, APPN only product, in my option (see my original reply), should not have to implement DLUS/DLUR. In this way, the dependent protocols "die out". My critique was that DLUR keeps these things around, which keeps my people needing to be familar with both APPN and "classic SNA". I'd love to have the new people never need to see an ACTLU, in any way, shape or form! RESPONDENT: Michael Cambria RESPONSE16(!!): <<< Start new thread from # 21401-SNA, APPN and ATM in S11 >>> Roy, I followed with interest the first part of this thread. I am wondering if you would be willing to comment on how DCE fits (or does not fit) into the "scheme" of things. IBM has done a lot of talking recently about DCE but it seems to have elements, such as directory services and security, that duplicate or overlap APPN. I am probably not seeing the bigger picture here. Is there any hook at all from APPN to DCE? RESPONDENT: Ted Shelly COMMENTS: This question and series of responses tracks a public e-mail discussion that was generated by the original question. Each response is listed in chronological order, and as can be seen, many of the responses (most) are more related to previous responses, although for the most part are relevant to the original question. ========================================================================= Subject: VTAM Estimating Storage Diskette Date: 10/01/94 Owner: Don Weinstein Compuserve?N Okay, here's the problem: you're getting storage shortages in VTAM, maybe even getting IST56x something messages on your console. You know it might be just some tuning that needs to be done, and perhaps you even added a whole new network or just a few major nodes with several thousand devices. CSA goes bonkers or private storage gets so tight you could snap it like a rubber band and use it for a slingshot. VTAM is about to crash and you need answers in a hurry. What do you do? Get your resume together? Thinking fast, you know the VTAM storage estimates diskette will save you, but it will take at least 2 - 3 weeks to order it from your SE, and you need it now! Call the support center? Nah! It'll still take overnight to get to you. Here's the solution: APPC Marketing Enablement and the wonderful folks at VTAM product support came up with some synergy! Now you can download the VTAM Storage Estimates diskettes directly from Compuserve by executing the command GO APPC and selecting the LIBRARY #8 TOOLS and UTILITES function. At this time only the VTAM 3.4.1 diskette is available, but the other VTAM versions should be there in about a week or so. All the files will begin with an EST prefix, so VTAM 3.4.1 is EST341 (this is good for VSE/VTAM 3.4.0 too). Here's the rest: EST41 - VTAM 4.1 for MVS/ESA Estimating Storage for VTAM EST42 - VTAM 4.2 for MVS/ESA Estimating Storage for VTAM EST342- VTAM 3.4.2 for MVS/ESA and VM VTAM 3.4.1 I know this is going to help everyone out there, so this should be a great boon to those who misplace that elusive little kit, and need it at the worst possible time: right now!! Architect: Don Weinstein (VTAM) Comments: ========================================================================= Subject: ADSM connectivity Date: 10/07/94 Owner: Steve Shomaker (VM Assistance) QUESTION: We are trying to use ADSM with OS/2, VTAM, and a 3174 w/APPN feature. We would like sample configurations for all pieces and how they relate to each other. We have gone through other channels with no success. ANSWER: Steve, do you already have a working APPC network? If not, you need to get the MPCONFIG, APING and GETSENSE packages from this BBS, and get that working first. RESPONDENT: Richard Gray APPC Market Enablement =============================================================================== SUBJECT: APPN using /36 DATE: 10/20/94 OWNER: Thomas Blockhaus QUESTION: I want to connect three (later more) IBM/36 system via APPN. IBM/36 ----> IBM/36 ----> IBM/36 A B C (APPC) (APPN) (APPC) A passthru session should be started from System A to System C via the internetwork node System B. Since the X.25 lines between the systems are public lines we can't leave them active round the clock due to the time charge. My question is: When Sys A enables the line for a passthru session to Sys C, the link between A and B is physically enabled. Is Sys B then able to connect (enable) the line to Sys C automatically to forward the request or has this part of the link to be active ??? Any answer or better solution highly appreciated ANSWER: The connection from node B to node C can be made physically active when the BIND for C from A is received at node B. The S/36 ENABLE command must have been run on node B so that the link betweem B and C is in an enabled state but not communicating, Communications will go active when the BIND is forwarded to C. The link from B to C must be configured as a switched virtual circuit (SVC). It should be configured on node B to auto-disconnect when it no longer needed by a session. The link from B to C will be activated upon the receipt of the BIND at node B. When the session between A and C UNBINDs, the link from B to C will disconnect. The link from A to B will always be active because of the CP-CP session between nodes A and B. To further reduce line charges, node A could be changed from a network node to a LEN. The SVC between nodes A and B would only activate then when the BIND for the A-C session flows. In an non-X.25 network, it is still possible to automatically connect and disconnect switched lines. This can be accomplished using SDLC switched lines in conjunction with the S/36 AUTOCALL feature or the V.25bis PRPQ. The system will dial out when a session is needed on a remote system and then disconnect the line when all session activity on that line has completed. RESPONDENT: Mike Landry COMMENTS: =============================================================================== SUBJECT: Class of Service DATE: 11/09/94 OWNER: Martin Hillier - Mattel QUESTION: Hi there. We are in the process of installing some APPC programs between AS/400'sd are trying to get these programs to "prefer" a didderent line to all other comms (DSPT and SNADS). I have a feeling that bias can be given to certain lines by tuning the class of service descriptions. This seems a bit confusing. Has anyone out there done this? Ta, Martin ANSWER: I have not used an AS400 but I do have knowledge in APPC and APPN. I believe you do indeed to need to modify the COS. The COS can be configured such that you can influence which connection is used. This can be based on cost, security, etc. The appc application will need to specify a mode which in turn gets mapped to a particular COS. This COS will then be used to search for a connection that satisfies it. This means that the cost, security, ... and other parameters are also specified on the individual connections. This can be complex to understand and configure. IBM has not exposed this in CM2 through the UI, although I believe you can set these parameters by manually editing the configuration file. I do not know how this is exposed in the AS400. All of this is explained in the IBM APPN Architecture reference. Hope this is a start. RESPONDENT: Wayne Weilnau RESPONSE2: I'm not sure if this is the easiest way, but here's one way to force TRS to prefer a particular line for a session. The Topology and Route Selection Services (TRS) component usually picks the best TGs and nodes based on how their SNA-defined characteristics (i.e. effective capacity, propagation delay, etc.) compare to the allowable characteristics ranges for the Class of Service (COS) specified. But you can use one of the three user-defined characteristics to force TRS to give a lower weight to your preferred line, for a particular COS. What you'll need to know is the COS you're using for these sessions. You'll also need to know what row in that COS table that your preferred line (TG) currently falls into, based on the characteristics of that TG. Whatever row this is tells you the weight given to that TG. The lower the weight, the more preference given to the TG. Since for AS/400 nodes, the user-defined characteristics default to a value of 128, modify the TG description of your TG to give one of those characteristics a lower number, say 1. Then, modify the acceptable ranges in the COS table for the same characteristic of all the higher rows, including the row your TG falls into, so that only values less than 128 are acceptable for any TGs. This forces all TGs with a 128 value for this field to fall into lower rows for that COS, resulting in higher weights and less preference than your preferred TG. For example, say you're using the #BATCH COS, and you find that the TG characteristics defined for your TG cause it to fall in the 4th row of that table. To make that TG have a lower weight for this COS than any other TG, set one of the user-defined characteristics for this TG to 1. Next modify the acceptable ranges for that characteristic in the #BATCH table in rows 1-4 to be 0-127 instead of 0-255. Now all other TGs, because they have a value of 128, must fall to rows 5-last before they are considered acceptable, thus giving them higher weight. Points to consider: + If you modify an already-defined COS, every time TRS uses that COS (on that node only) to build routes for new sessions, the TG with the modified characteristic will have the lowest weight and will probably be used most or all of the time. + TRS may still prefer other TGs over your modified TG if they result in a lower weight end-to-end path (i.e. using them results in fewer hops or leads to more desireable TGs/nodes than the modified TG does). Since products vary as to how to use the Node Operator Facility (NOF) in APPN to tweak things like COS's and TG characteristics, I'm including here some info. I received from an AS/400 designer (Paul Michenfelder) as to how to do this on an AS/400 node: You can use the Work with COS Description (WRKCOSD) command to modify the COS table. On the WRKCOSD command just specify the COS description(s) you want to work with and then select the Change option from the Work with COSD screen. All TG characteristics are specified on the Line Description except the the user-defined values. The user-defined values can be specified on the Line Description and/or Controller Description. A value other than *LIND on the Controller Description overrides the value specified on the Line Description. Use the Work with Configuration Status (WRKCFGSTS) command to work with Line and Controller Descriptions. For Line Desc specify: WRKCFGSTS *LIN For Controller Desc specify: WRKCFGSTS *CTL On the WRKCFGSTS screen you select option 8 to work with the Line or Controller Desc. On the Work with Desc screen you select option 2 to change the Line or Controller Desc. RESPONDENT: Tim Hefel COMMENTS: =============================================================================== SUBJECT: Dependent LU DATE: 11/14/95 OWNER: Anthony Johnston QUESTION: We are looking at installing the folowing communications network which but I have some nagging doubts about it. The situation is like this.... 2 Data Centers (200 miles apart) each with 2 * 3172's connected to an Ethernet segment (running VTAM 4.2 which can provide Dependant LU Server) The ethernet segments are bridged (using pairs of Welfleet routers) over the wide area to 40 geographically seperate offices. A Novell SAA gateway will act as comms server for up to 120 client P.C. users in each office. We will be using vanilla 3270 dependant LU2 services. In the near future we would like to move to APPN. However as I understand it the Novell SAA gateway will only support a LEN node. The Welfleet will support an APPN Network node, but I'm unsure if it supports DL/R. I *think* that we will be able to connect the LEN node to the NN (but we will need to statically defining its resources), however I'm unsure of the mechanisms needed to carry the LU2 session through to our data centres. I'm aware that dependant LU's can be supported by previous versions of VTAM in an APPN network but that this support would require (in this case) the SAA gateway to be adjacent to the boundary function - ie the VTAM/3172 combination, which (if I've understood the Dependant LU restrictions) it isn't! I guess the questions I'm asking are:- 1) If the SAA gateway is a LEN node is the nearest NN *REQUIRED* to suport DL/R? 2) Does the SAA gateway support EN rather than LEN? can anyone offer any assistance? I'll ask this in both the APPN & Netware Forums. ANSWER: SAA Gateway does not support DLUR, so LEN vs. EN is irrelevant. If Wellfleet were to ship a product that implemented DLUR, you would be able to configure the SAA gateway as a downstream PU from their router(s), thus realizing all the coolness of DLUR and APPN. RESPONDENT: Richard Gray COMMENTS: =============================================================================== Subject: XID rules Date: 01/05/95 Owner: Mike Allen Compuserve? N (Wall Data) Message#: Question: Can you clear up a question about pre-negotiation XID exchange? In the APPN book, p. 9-22 (my copy is dated March 93), under the heading "Link Activation", the 3rd bullet reads: "When a link activation exchange includes a prenegotiation XID3, it includes a full prenegotiation exchange, i.e., each node will send and receive a prenegotiation XID3, before entering into the negotiation- proceeding phase. "Some back-level nodes may bypass the prenegotiation exchange. Therefore nodes that send out a prenegotiation XID3 support exchanges with nodes that send a negotiation-proceeding XID3 as the initial nonnull XID during link activation or respond to a prenegotiation XID3 with a negotiation-proceeding XID3." What does this text require? >>>>1- If your product does not need an XID3(pn) -AND- you KNOW that >>>> the adjacent node also does not need an XID3(pn) then you >>>> do not 'have to' send one. >>>>2- We recommend all products start link activation with: >>>> - 1st a NULL XID3 >>>> - 2nd an XID3(pn). >>>>3- All products must be able to receive an XID3(pn). >>>>4- If your products receives an XID3(pn) you 'should' return >>>> an XID3(pn). Some products don't, so you shouldn't fail the >>>> link activation if they respond to an XID3(pn) with an XID3(np). What does "back-level" mean in this case -- pre-APPN R1? >>>> Anybody who can't send -or- process an XID3(pn) If a product is "back-level" on this point, is it non-compliant? >>>> What's the difference what it is called. The issue is who can >>>> and who can't link with everybody they want to. >>>> If you do 2-4 above you have the best chance of linking to anyone. >>>> If you want to save code and do less you take your chances. This text also seems to require that up-level products support this "back-level" exchange for interoperability. Is that the case? >>>> I would say yes, BUT I repeat: >>>> If you want to save code and do less you take your chances. Any clarification would be appreciated. >>>> You got it. Also, is there any way to get an online version of the APPN book? I noticed that the "Best of APPC..." CD does not have a softcopy of that book. It would be very helpful to have that book online. >>>> Not my area. Security(Public/Private): Public Architect: Jim Amundson Comments: ======================================================================= Subject: Numerous Base & Options Questions Date: 01/05/95 Owner: Mike Allen Compuserve? N (Wall Data) Message#: 1. What is the difference between 053 "Participate in Network Searches" and 055 "Broadcast and Directed Searches"? Both are base for an EN, but the descriptions are very similar. 2. Why is 057 "Partial Directory Entries" base function for an EN? I have read everything I can find in the book about this function, and it seems to be useful for a NN, but there is little rationale given for putting the function on an EN. The only text I can find about an EN implementation is the footnote on page 8-56, which reads: "... On the other hand, the reason for carrying partially specified names in an end node directory is to represent groups of similarly named LUs residing within the end node itself; this permits a saving in the directory, but the fully specified names would still need to be known by ASM, ..." So the motivation for supporting partial entries on an EN is to allow an internal optimization of DS control blocks in an EN that supports a large number of LUs with similar names. There is no manifestation of this function in directory flows, since partial entries cannot appear in register flows or locate flows. Thus it would seem to be entirely an implementation issue (user interface and internal optimizations) and not an architecture requirement. For an EN-only product that runs on end user workstations, this really does not make sense. If I have missed something, please enlighten me! 3. For 081 "Class-of-Service Manager", is it OK to provide mode-to-COS mapping where only the standard COSs: CPSVCMG SNASVCMG #CONNECT #INTER #INTERSC #BATCH #BATCHSC are supported? On an end-user workstation there may not be a real need to provide for the creation of non-standard COS definitions (just imagine how much help text would be required in the GUI to explain what all the stuff in a COS means!). Is it OK to provide a COS Manager that does not allow the user to define a non-standard COS? 4. Regarding 082 "Route Randomization", I have read what is required for an EN, and it is not much, but I have to make the observation that this seems like an odd function to require in an end user workstation product. It makes much more sense on a NN, where there is a realistic chance of having a choice in equally-weighted routes to select from. How often is an end node going to have a selection of equally-weighted single-hop routes? On a workstation end node, there is typically one adapter card connected to one LAN. A user actually could define multiple links across the LAN to another system (using different SAPs for each link), so there could be multiple links, with the same weight. (I am not aware of any good reason for an end user to do this.) So what is the point of randomizing in this case? The links are going through the same adapter and across the same transmission medium, so it makes no difference whatsoever in performance or network load. Even if the workstation had two adapters, the same argument would hold -- there is little real benefit to randomizing equivalent single-hop routes at an end node. One of the biggest motivations for building an APPN network is to remove the requirement for end nodes to pre-define connections to partner systems in the first place. The end node relies upon its network node server to calculate the most appropriate route to a desired partner. That's why I have to question why this function is a required base for an end node. 5. Regarding 090 "Common Node Operator Command Set", 14 node operator functions are listed, with the notation "product specific". Are we to assume that it is entirely up to us, as product implementers, to select which of these 14 functions make sense to provide in our product? Also, is it up to us to decide what kind of user interface we wish to provide for each function (i.e., there is no implied requirement to support the NOF command syntax)? 6. Regarding 091 "Network Node Operator Command Set", the description clearly says that these are network node functions, so why doesn't the APPN EN column read "n/a"? Is this just a typo? 7. For 101 "Fixed Session-Level Pacing" and 102 "Adaptive Session-Level Pacing", the reference is to "Chapter 11, INTERMEDIATE SESSION ROUTING", so am I correct in assuming that the functions referred to are actually support for fixed session-level pacing and adaptive session-level pacing in intermediate session routing? Except for the chapter reference, these items seem to say that fixed and adaptive pacing are not applicable to end node implementations. Please understand that I am not just nit-picking, I want to be absolutely sure that I understand what the architecture says. ANSWER: 1. RC: 1. 053 - Participate in Network Searches refers to the ability to handle Locate flows from other nodes. 055 - Broadcast and Directed Searches refers to the ability to originate Locate flows for search procedures. MP: I'm don't see, and can't recall, any reason why I broke this base function into 2 pieces. We could combine them if we wanted to. 2. RC: 2. Beats me why this is base. I agree with your analysis that it should be optional. Shall I add this suggestion to the discussion we're starting at the AIW APPN Reference SIG to re-think base and options? MP: Mike's analysis seems to be correct. 3. TH:For end node implementations, it's OK to support only the SNA-defined COS's. It is not required for EN implementations to support a DEFINE_COS NOF command that can be used to create a new COS. 4. TH:For end nodes that support parallel TGs to partner nodes, route randomization support is required if the characteristics of the parallel TGs result in the same weight for the specified COS. 5. MP: I would like to get a discussion going at the AIW of defining a required base set of NOF commands. Unfortunately, at the time when I was trying to standardize these internally at IBM, several of the then-existing APPN products would not have had compliant NOFs. In order to get agreement on the base & options for V1 and V2, some tradeoffs were made, and the common NOF command set was one thing that fell out. Perhaps the discussion should be resurrected. 6. MP: Yes, it's a typo and needs to be fixed in next release of the arch. 7. GD:You are correct that 101 and 102 are support in ISR for fixed and adaptive pacing. This very subject was discussed in the APPN Architecture Reference SIG at the last AIW. See the mail exploder for AIW-APPN-REFERENCE for more discussion. Security(Public/Private): Public Architects: Gary Dudley (GD), Ralph Case (RC), Tim Hefel (TH), Marcia Peters (MP) ======================================================================== Subject: COS Support in End Nodes Date: 01/11/95 Owner: Mike Allen Compuserve? N (Wall Data) Message#: Question: Can you tell me what base function 036 COS/TPF consists of in an EN that does not implement optional function 081 COS MGR? Appendix A says that 036 COS/TPF is base, but everywhere it is mentioned in the session services chapter it is referred to as an optional function. Is there a more recent version of the SS chapter that makes this clearer? ANSWER: Function set 082 pertains to the a) mode-to-COS mapping and b) route building based on COS functions. ENs are not required to do either of these, although every EN product I know of does perform these functions. Function set 036 pertains to the following functions: a) As an EN, when receiving a Locate/CD-Init as a destination node for a route request, the COS in that GDS variable is to be returned intact without stripping it off, when responding to the Locate/CD-Init. b) For multihop routes, the EN's server will use a COS to build the route. and always includes that COS on the Locate/CD-Init. reply. The origin EN must use the COS on this reply when building the BIND for that session. These two functions are required of EN implementations. Security(Public/Private): Public Architect: Tim Hefel ======================================================================== Subject: Errors Detected in XID Processing Date: 02/14/95 Owner: Mike Allen Compuserve? N (Wall Data) Message#: Question: In the APPN Reference on page 9-52, there is a table "Errors Detected in XID Processing". The *implication* of this table is that all of these sense values represent required validity checks. However, in going through the structured prose, FSMs, and description of XID Format 3 I-field on page 9-221, there are inconsistencies. In those cases where one of the sense codes on page 9-52 is not referred to anywhere else, I am assumed that the implied test is required. >>>> NO. Some old products may set these code. See note #1 above for >>>> how you can function. However, the tests implied by the following codes in the table seem to be in conflict with statements in the structured prose or FSMs, so should I assume that the validity checks are *prohibited*? 0809003A - Null XID received when activation XID3 expected >>>> ACCEPT 0809003C - Preneg XID3 received when NOESI or neg proceeding expected >>>> ACCEPT 08090041 - Negotiation proceeding received when prenegotiation expected >>>> ACCEPT 08090047 - XID received before modesetting command completed >>>> ACCEPT 10160014 - NRM station indicated neg role but previously was non-neg >>>> IGNORE if the previously ESI=non-neg was on a prior link activation. >>>> ERROR if the previously ESI=non-neg was during this link activation. >>>> ACCEPT if you want. If you want to allow this, who is to care? In FSM_XID3 on page 9-182, "Note 2" at the bottom of the page says that XID processing should *not* be terminated with a CV22 error if XIDs are received out of sequence. The out-of-sequence XID is responded to with a copy of the last XID sent by this node. >>>> This is the principle you should follow! 08090048 - NRM secondary sent unsolicited XID In FSM_XID3 on page 9-182, "Note 1" at the bottom of the page says that, while it is an error if an NRM secondary station sends an unsolicited XID after the mode-setting sequence has begun, the stray XID is not a problem for CS and should simply be ignored. >>>> This is the principle you should follow! Can you please clarify this point for me? If this interpretation is correct, will the table on page 9-52 be corrected in the next issue of the book? >>>> Hopefully. MORE GENERAL COMMENTS: Note #1 ------- Some general comments. Originally the architecture listed how thing should go and provided a test and error code for a lot of thing. A product however is not interested in policing the network but bringing up a link. Thus a product may actually want to accept minor errors if they don't hinder the valid operation of the link. If the question you ask falls in this category I will answer with 'IGNORE' if I thing you could or should. Note #2 ------- In the real world with delays, race conditions, and DLC time-outs and retransmissions; XID's can and will arrive in sequences other than expected. FSM_XID3 was written to deal with the real world and accept everything it can and still get a valid link up. If the question you ask falls in this category I will answer with 'ACCEPT' since I think you should ignore the problem. Security(Public/Private): Public Architect: Jim Amundson ========================================================================= Subject: Sense data for inconsistent netid.cpname on activation XID3 Date: 02/14/95 Owner: Mike Allen Compuserve? N (Wall Data) Message#: I'm looking at XID3_ACTIVATION_CHECKS on page 9-165 of the APPN book. The pseudo code says to verify that the adjacent node has been consistent in the name it has sent in CV0E on XID3s during an activation exchange. However, there is no indication about what sense value to use for that error. The table of applicable sense codes on page 9-237 does not include one for this error, nor is there one in the master list of sense codes on 9-52. Does this lack of a sense code indicate that this check is unnecessary, or is there another sense value that should be used? ANSWER: No, this is a valid check and the sense code set is 0806002C Security(Public/Private): Public Architect: Jim Amundson ======================================================================== Subject: Sense data for inconsistent netid.cpname on activation XID3 Date: 02/16/95 Owner: Mike Allen Compuserve? N (Wall Data) Message#: Jim, Thanks for the clarification! I agree wholeheartedly with the principle of performing no more error checking than is absolutely necessary. When I started looking at XID error checking, I was shocked by the list of 60+ sense codes in the APPN Reference. I am glad that some of them are not recommended anymore. I just came across one more that I have to ask about. 10160018 Adjacent node is APPN but not support adaptive BIND pacing as a sender and receiver. Making this check would seem to be a way to guarantee a migration problem, since there are existing APPN products in the field that don't support BIND pacing (Wall Data's RUMBA, for example). We have recently added bind pacing, but we are certainly not interested in rejecting XIDs from previous releases of our own product. No other APPN product that we have ever connected to sends this sense code. Should this one be ignored, too? ANSWER: You should never send an XID that does not support adaptive BIND pacing as a sender and receiver. Thus if you receive a CV22 with 10160018 somebody has a problem and it better not be ignored. If you should receive an XID that does not support adaptive BIND pacing as a sender and receiver you can: - Accept- if you are not concerned that the adjacent node may flood you with BINDs. -or- - Reject- if you are concerned that the adjacent node may flood you with BINDs (use 10160018). Security(Public/Private): Public Architect: Jim Amundson =============================================================================== SUBJECT: AFTP to FTP by Anynet DATE: 2/20/95 OWNER: Rainer Foeppl QUESTION: Is it possible to to a filetransfer in the following configuration: AFTP / APPC ---- APPN----ANYNET---TCP/IP---FTP ANSWER: No, AnyNet is Like-API to Like-API only. AFTP does have an API, so one could write a gateway. RESPONDENT: Richard Gray COMMENTS: ========================================================================= Subject: APPN Design Using a Connection Network Date: 2/28/95 Owner: Mark Lehman QUESTION: I am putting together a 12 site APPN network. Each site will have a CM/2 machine defined as a NN. We are using Frame Relay (via RXR/2). 1) Are there any advantages to using a CONNECTION Network to connect the NN's (we are examining a fully meshed Frame Relay network) 2) What are the performance implications of using a Connection Network versus defining all of the connections in a fully meshed network of this size? (ie. how much work will the CM/2 NN have to do in terms of 'overhead' regarding topology updates and other NN functions with connections to 11 other NN's) Any other thoughts or manuals I should read would be beneficial. RESPONSES: GD: APPN connection networks are only defined for LANs; therefore, you have no alternative to system defining the links. However, your frame relay network is providing only permanent virtual circuits (PVCs), and system definition for these is already required. JF: Doesn't RXR/2 look like a token ring connection to CM/2? If so then I would suspect that you can use connection network (since CM/2 will think it is on a LAN). Someone from CM/2 needs to confirm that. ML: Yes, RXR/2 can be configured such that CM/2 thinks the frame relay is a Token Ring network. My previous questions ask about CONNECTION NETWORK vs. fully meshed. Any comments on that? CM:Interesting - I would expect that the theoretical requirement is to ensure that you have sufficient permanent connections to ensure that TDUs can flow from any one NN to any other NN. Then any other NN to NN connections will be built over the Virtual Routing Node as required by normal topology analysis versus the COS. Don't forget the Connection Network "trick" that the weights are averaged rather than added over the Virtual Routing Node. Maybe you should allow that at least one physical connection could break while still keeping univers al connectivity for TDUs. JF: Yes, I prefer CN over fully meshed ... less def and better performance. TH: Using connection network greatly reduces the amount of manual definition you have to do, plus makes it far less painless for you if changes need to be made to your network (adding/removing sites, links, etc.). Here are some important things you need to know regarding the use of a connection network: + as long as APPN thinks it's on a LAN, you can define a connection network over frame relay. It sounds like Route Expander/2 does the proper LAN emulation, and if so, you're in business. + APPN treats a connection network as a shared transport network, meaning it assumes each node connected to a connection network can directly connect to all other nodes that are also connected to it. Therefore, any node you define to a connection network must have a complete mesh connection to all other nodes you define as connected to it. Otherwise, APPN may build routes that will fail. + CP-CP sessions can not be carried over a connection network. Because of this, and especially because all of your nodes using frame relay are NNs, you also must define some direct connections for each of your NNs. Probably two direct connections for each NN, so that they are connected in a ring-like topology, is sufficient for your network. Now, here are the benefits of using a connection network for your network: + Far fewer link definitions: Assuming your 12 NNs had meshed FR PVC connections to each other, without a connection network you have to manually create 11 link definitions on each of the 12 NNs. Defining a connection network, however, you only need to define a link to the connection network plus two links to two other NNs (to carry the CP-CP sessions), for each NN. This is 8 fewer link definitions per NN. + Much more dynamic and flexible: when adding/removing NNs to/from the frame relay connection network, you only need to modify the two NNs that have/had defined direct links to that node. Without a connection network, you have to modify every NN on the frame relay "cloud". This also applies to adding or removing links to the FR cloud. CM: It's actually becoming more interesting than I thought at first. In your original append, you asked for reading material. I would suggest The APPN Tutorial "red book", GG24-3669-2. Since you have a logical bridged LAN, you could theoretically have one APPN Network Node with every other node defined as an APPN End Node with a single connection to that APPN Network Node. You could then have that APPN Network Node manage all session setups over the Virtual Routing Node representing the logical bridged LAN. There would be no TDU flow and no broadcast Locates. MP: I remember thinking about this last year. I believe there are issues with the way that RXR/2 presents a virtual mac address to CM/2 that mean that you had to make sure that the same dlci on each node pointed to the same node ie on nodes a,b,c,d,... dlci 2 was the connection to node z else the mac address for z looked differant to each node. I was pretty sure this wasn't allowed by APPN. If i remember correctly (i am sure that some one will correct me if i don't) the red book on rxr/2 was even more cautious and reccommended that you don't do connection networks. I think there was a discussion on this (from the rxr side) in the rxr forum. Read the red book, it is very good ML: With RXR/2 there are two methods of representing the 'virtual' MAC address of the frame relay port to CM/2. 1) Routed SNA - where the DLCI number is contained in the MAC address 2) Bridge Frame - where the frame carries the source and destination MAC address, and this MAC address is defined in LAPS (and is independant of the DLCI) Only Bridge Frame format can be used if a Connection Network is configured. (as MP states) TH: More things to chew on regarding the connection network debate: You're right to define at least one NN at each site if ENs also exist at each site and you wish to establish sessions between ENs of different sites. If you minimize the number of CP-CP sessions each NN has with other NNs (around 2/NN is a good rule of thumb - see my previous note on how to do this with your setup), the amount of TDU overhead on your network will probably be insignificant. Also, the number of CP-CP sessions an NN has with client ENs does not affect TDU processing overhead in any way because TDUs never flow over these links. Defining a connection network in your network will not degrade session routing performance in any way. In fact, it allows you to establish a direct connection to any other node also connected to the VRN, which is the best performance you can hope for. JF: Yeh, these are the kinds of things that people need to realize about the power of APPN. Given the number of boxes that make the world appear as "one big LAN" I can use APPN directory to eliminate lots of definitions that I might have to do otherwise. RESPONDENTS: Jim Fletcher (JF) Chris Mason (CM) Mike Prendergast (MP) Mark Lehman (ML) Tim Hefel (TH) Gary Dudley (GD) COMMENTS: This question/answer item is a composite of an e-mail discussion that occurred, and was originated by the question Mark Lehman posed under the QUESTION section. Each respondent's entry is listed in chronological order, therefore in many of the cases may be a response to a previous response. ========================================================================= Subject: APPN and SNI Date: 3/07/95 Owner: Mark Remes, Kredietbank QUESTION: Is there a way to connect a APPN NN to another NN in a different netid, other than to pass through VTAM? NET1.EN1 -- -- NET2.EN2 -- NET1.NN1 -- -- NET2.NN2 -- Can EN1 allocate EN2 via NET1.NN1 and NET2.NN2? ANSWER: RB: AS/400 includes Peripheral Border Node support, which would allow you to do what you are trying to do without a VTAM. For this to work, either one or both of NET1.NN1 or NET2.NN2 would need to be an AS/400. If you don't have an AS/400 or VTAM to provide Border Node support, then you can use a LEN connection between NET1.NN1 and NET2.NN2. You could then define a wildcard entry on both NN1 and NN2, each pointing to the other. Session between EN1 and EN2 can then be established. CM:There was a discussion about this a while ago where the Network Node, on both sides was CM/2. As the dicussion was going on, a fix got created, not necessarily related to the FORUM discussion, that allowed a CM/2 Network Node to re-calculate the RSCV when it is handling a LEN node's incoming BIND. This will then allow two Network Nodes to be connected to each other as LEN Nodes and, hence, for there to be a change of NETID. The requirement which gave rise to the disscussion was in the OS2CM2 FORUM on IBMPC. Whether this sort of connection is formally supported by APPN architecture seemed not to get resolved, so it is not possible to say it would work in every case. One point that did emerge is that VTAM, without Border Node support, would be able to do this. By the way, this has nothing really to do with SNI, maybe SNA (APPN) network interconnection - without capital letters :-) RESPONDENTS: Roy Brabson (RB) Chris Mason (CM)